Attorney Docket No.: FOUND-0058 (034103-049) 
REMARKS 

The Final Office Action mailed June 18, 2007 has been carefully considered. 
Reconsideration in view of the following remarks is respectfully requested. 

Claim Status and Amendment to the Claims 
Claims 1 -46 are currently pending. 
No claims stand allowed. 

New claims 44-46 particularly point out and distinctly claim subject matter regarded as 
the invention. Support for these claims may be found in the specification and figures as 
originally filed, for example paragraph 61. 

With this Amendment it is respectfully submitted the claims satisfy the statutory 
requirements. 

Claims 12,30, and 35-37 

As an initial matter, the Applicants note that Claims 12, 30, and 35-37 were not 

mentioned in the last Office Action. 1 Claims 12 and 13 were included in the present application 

as filed on September 4, 2003 and remain unamended. Claims 35-37 were added in the 

Applicant's Response mailed March 15, 2007. According to the M.P.E.P., 

In every Office action, each pending claim should be mentioned by number, and 
its treatment or status given. Since a claim retains its original numeral throughout 
the prosecution of the application, its history through successive actions is thus 
easily traceable. Each action should include a summary of the status of all claims 
presented for examination. 



1 Office Action mailed June 18, 2007. 

2 M.P.E.P § 707.07(i). 
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Considering that the Examiner has not provided any comments or rebuttal to Applicant's 

argument, it can be assumed that the Examiner agrees to the Applicants' arguments and that 

Claims 12, 30, and 35-37 are allowable. 3 



The 35 U.S.C. § 102 Rejection 

Claims 1-3, 6-7,11 ,13-15, 17, 23-25 and 28-29 stand rejected under 35 U.S.C. § 102(e) 
as allegedly being anticipated by Kanuri et al. 4 5 This rejection is respectfully traversed. 



According to the M.P.E.P., a claim is anticipated under 35 U.S.C. § 102(a), (b) and (e) 
only if each and every element as set forth in the claim is found, either expressly or inherently 
described, in a single prior art reference. 6 



Claim 1 

Claim 1 recites: 

A layer 2 network access device for providing network security, comprising: a 
plurality of input ports; 

a switching fabric in the layer 2 network access device for routing data received 
on said plurality of input ports to at least one output port; and 

control logic in the layer 2 network access device adapted to authenticate a 
physical address of a user device coupled to one of said plurality of input 
ports, to authenticate user information provided by a user of said user device 
only if said physical address is valid, and to restrict access to said one of said 
plurality of input ports in accordance with a user policy associated with said 
user information only if said user information is valid. 

The Examiner states: 



In re Herrmann, 261 F.2d 598 (CCPA 1958) (The court noted that since applicant's arguments were not questioned 
by the examiner, the court was constrained to accept the arguments at face value and thus held the claims to be 
allowable); See In re Soni, 54 F.3d 746 (Fed. Cir. 1995). 

4 U.S. Patent No. 6,807,179 to Kanuri et al. 

5 Office Action at H 6. 

6 Manual of Patent Examining Procedure (MPEP) § 2131. See also Verdegaal Bros. v. Union Oil Co. of California, 
814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). 
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... Kanuri et al. teaches a layer 2 network access device for providing network 
security, comprising: a plurality of input ports (Fig 1, 12:22; Col 3, lines 25-67; 
multiport switch); a switching fabric in the layer 2 network access device for 
routing data received on said plurality of input ports to at least one output port 
(Fig 1.28; Col 3, lines 25-67; switch fabric; Col 4, lines 7-52; layer 2 switch); and 
control logic in the layer 2 network access device (Col 3, line 28 to Col 5, line 65: 
the switch; MAC module; switching (rules) logic) adapted to authenticate a 
physical address of a user device coupled to one of said plurality of input ports 
(Col 3, line 28 to Col 5, line 65; matching MAC addresses), to authenticate user 
information provided by a user of said user device only if said physical address is 
valid (Col 3, line 54 to Col 4, line 34; Col 5, lines 10-65; user, or network nodes' 
attributes/ policies/ information; user defined policies/ attributes; authenticating 
VLAN field/ index/information, and MAC addresses specific to user/ network 
node/ data frame), and to restrict access to said one of said plurality of input ports 
in accordance with a user policy associated with said user information only if said 
user information is valid (Fig 2:40; associated port, MAC and VLAN information; 
Fig 3, step 70-106; Col 5, lines 43-60; if in step 74 the switching rules logic 
determined a match between MAC... VLAN index ... (then) checks in step 76 
whether port ...; the examiner interprets switching "rules" logic as policy; port 
filtering). 7 

The Applicants respectfully disagree for the reasons set forth below. 

Kanuri et al. Does Not Disclose To Authenticate User Information Provided By A User Of Said 
User Device Only If Said Physical Address Is Valid, And To Restrict Access To Said One Of 
Said Plurality Of Input Ports In Accordance With A User Policy Associated With Said User 
Information Only If Said User Information Is Valid 

In support of the Examiner's contention that Kanuri et al. discloses authenticating user 

information provided by a user of said user device only if said physical address is valid, the 

Examiner refers to the following portion of Kanuri et al. : 

The switch 12 includes network switch ports 22, and a switch fabric 28. Each 
network switch port 22 includes a media access control (MAC) module 24 that 
transmits and receives layer 2 type data packets to the associated network stations 
14 or 16, and port filters 26. Each port filter 26, also referred to as a packet 
classifier, is configured for identifying a user-selected attribute of the layer 2 type 
data frame, described below, and outputting the relevant switching information 
(e.g., whether the user-selected attribute was detected) to the switch fabric 28. As 
described below, the switch fabric 28 is configured for making trunk-based layer 2 
switching decisions for received layer 2 type data packets. 

7 Office Action at p. 3. 
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As shown in FIG. 1, the switch 12 has an associated host CPU 30 and a buffer 
memory 32, for example an SSRAM. The host CPU 30 controls the overall 
operations of the corresponding switch 12, including programming of the port 
filters 26 and the switch fabric 28. The buffer memory 32 is used by the 
corresponding switch 12 to store layer 2 type data frames while the switch fabric 
28 is processing forwarding decisions for the received layer 2 type data packets. 
The switch fabric 28 is configured for performing layer 2 switching decisions and 
switching decisions that implement user-defined switching policies; such user- 
defined switching policies may include supporting trunk-based traffic having a 
prescribed user-selected attribute, for example having been determined to belong 
to a prescribed flow, for example an IGMP media flow or other flow having a 
prescribed TCP source address and/port TCP destination address, or granting 
sufficient switch resources to ensure a guaranteed quality of service (e.g., reserved 
bandwidth or guaranteed latency). 

According to the disclosed embodiment, each port filter 26 of FIG. 1 is configured 
for identifying user-selected attributes, from a received layer 2 type data frame, 
that are used by the switching logic 28 to perform trunk-based switching 
decisions. The port filter 26 can be implemented as a state machine that monitors 
the bytes coming in from the network, hence the state machine can analyze the 
layer 2 type data frame for the presence of prescribed user-selected attributes (e.g., 
TCP source port and/or TCP destination port) on a per-byte basis as the bytes of 
packet data of the data frame are received by the network switch port. In addition, 
the port filter 26 can be configured for multiple simultaneous comparisons of the 
incoming packet data with multiple templates that specify respective user-selected 
attributes, enabling the port filter 26 to simultaneously determine the presence of a 
plurality of user-selected attributes as the layer 2 type data frame is received. 8 

The above disclosure of Kanuri et al. speaks generally about performing layer 2 switching 
decisions that implement user-defined switching policies. Examples of such user-defined 
switching policies "include supporting trunk-based traffic having a prescribed user-selected 
attribute, for example having been determined to belong to a prescribed flow, for example an 
IGMP media flow or other flow having a prescribed TCP source address and/port TCP 
destination address, or granting sufficient switch resources to ensure a guaranteed quality of 
service (e.g., reserved bandwidth or guaranteed latency)." 9 But nowhere does the cited portion of 
Kanuri et al. disclose authenticating user information provided by a user of said user device, let 



Kanuri et al. at col. 3 1. 54 to col 4 1. 54. 
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alone authenticating user information provided by a user of said user device only if said physical 

address is valid as required by Claim 1 . The Examiner has not identified in Kanuri et al. user 

information provided by the user of the user device. The Applicants respectfully submit the 

Examiner's attempt to equate authenticating user information provided by a user of a user device 

with merely identifying the presence of user-selected attributes in a received layer 2 type data 

frame is improper. 



The Examiner also refers to the following portion of Kanuri et al. in support of the 
Examiner's contention that Kanuri et al. discloses authenticating user information provided by a 
user of said user device only if said physical address is valid, the Examiner: 

Hence, the switching rules logic 42 can determine which trunk a port belongs to 
by accessing the trunk table by the corresponding port number. 
The trunk distribution table 48 is a thirty-two row by eight column wide table 
configured for storing, for each of eight identified trunk fields 60, the switch ports 
22 that serve the corresponding identified trunk 20. As illustrated in FIG. 2, 
switch ports 1-4 are assigned to "Trunkl" specified in trunk field 60.sub.l, switch 
ports 5-8 are assigned to "Trunk2" specified in trunk field 60. sub. 2, switch ports 
5-8 are assigned to f, Trunk3" specified in trunk field 60.sub.3, etc. In addition, the 
assigned ports are stored by the host CPU 30 as a prescribed repeating sequence 
within the corresponding column 60 of the trunk distribution table 48, enabling 
the switching rules logic 42 to select any one of the ports 22 associated with a 
given trunk field 60 by generating a hash key index value 62 in the hash key 
generator 46 based on selected attributes within the received layer 2 type data 
frame, for example MAC source address, MAC destination address, TCP source 
port, and/or TCP destination port. Hence, the switching rules logic 42 accesses the 
trunk distribution table 48 by first determining a destination switch port from the 
address table 40. Upon determining the destination switch port from the port 
vector field 58 corresponding to a matched destination MAC address 52 or a 
VLAN field 56, the switching rules logic 42 determines the corresponding served 
trunk from the trunk table 44. Upon determining the output trunk from the trunk 
table 44, the switching rules logic 42 accesses the column for the identified output 
trunk 60 in the trunk distribution table 48, and accesses one of the rows of the 
table 48 based on the corresponding hash key index value 62 generated by the 
hash key generator 46. 



9 Kanuri et al. at col. 4 11. 10-16. 
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FIG. 3 is a diagram illustrating the method generating trunk-based switching 
decisions by the switch fabric 28 according to an embodiment of the present 
invention. The method begins by the switching rules logic 42 receiving, from the 
switch port 22, layer 2 header information for the received data packet (including 
MAC source address, MAC destination address, VLAN information), and an 
indication from the corresponding packet classifier module 26 whether the 
received data packet includes a prescribed pattern corresponding to a prescribed 
data flow (e.g., by identifying TCP source port and/or TCP destination port). As 
described above, the host CPU 30 may program the port filter 26 of each network 
switch port 22 to identify any one of a plurality of prescribed patterns, such that 
the port filter 26 may be able to distinguish between IGMP frames, SMTP frames, 
LDAP frames, etc., as well as identify prescribed data flows. Alternatively, the 
switching rules logic 42 may include a parsing engine to identify the MAC 
addresses and the TCP ports. 

The switching rules logic 42 performs an ingress check in step 70, for example by 
confirming according to prescribed ingress rules that the received data packet is a 
valid data frame. The switching rules logic 42 then searches the address table 40 
in step 72 based on the source MAC address in the received data frame to confirm 
that the transmitting network node information is stored in the address table 40. If 
in step 74 the switching rules logic 42 determines a match between the source 
MAC address and/or the VLAN index with an address table entry 50, the 
switching rules logic 42 checks in step 76 whether the port field 54 matches the 
identifier of the switch port 22 having received the data packet; if there is no 
match, and if in step 78 the port does not belong to the same trunk, then the entry 
is overwritten in step 80, otherwise a hit bit is set in steps 82 or 84 to prevent 
subsequent deletion of the entry 50 by aging functions. 

If in step 74 there is no match of the source MAC address or the VLAN index 
with any entry in the address table 40, the switching rules logic 42 learns the new 
address in step 86 and stores the new address information as a new entry in the 
address table 40. 10 



The above disclosure of Kanuri et al. speaks generally about generating trunk-based 
switching decisions which include performing ingress checks on a received data packet based on 
a source MAC address. But nowhere does the cited portion of Kanuri et al. disclose 
authenticating user information provided by a user of said user device, let alone authenticating 
user information provided by a user of said user device only if said physical address is valid as 
required by Claim 1 . Again, the Applicants respectfully submit the Examiner's attempt to equate 



Kanuri et al. at col. 5 11. 10-65. 
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authenticating user information provided by a user of a user device with merely identifying the 

presence of user-selected attributes in a received layer 2 type data frame is improper. 

In support of the Examiner's contention that Kanuri et al. discloses to restrict access to 

said one of said plurality of input ports in accordance with a user policy associated with said user 

information only if said user information is valid, the Examiner refers to step 76 of FIG. 3. The 

corresponding disclosure in Kanuri et al. recites: 

The switching rules logic 42 performs an ingress check in step 70, for example by 
confirming according to prescribed ingress rules that the received data packet is a 
valid data frame. The switching rules logic 42 then searches the address table 40 
in step 72 based on the source MAC address in the received data frame to confirm 
that the transmitting network node information is stored in the address table 40. If 
in step 74 the switching rules logic 42 determines a match between the source 
MAC address and/or the VLAN index with an address table entry 50, the 
switching rules logic 42 checks in step 76 whether the port field 54 matches the 
identifier of the switch port 22 having received the data packet; if there is no 
match, and if in step 78 the port does not belong to the same trunk, then the entry 
is overwritten in step 80, otherwise a hit bit is set in steps 82 or 84 to prevent 
subsequent deletion of the entry 50 by aging functions. 11 

Nowhere does the portion of Kanuri et al. cited by the Examiner disclose restricting access to 
said one of said plurality of input ports in accordance with a user policy associated with said user 
information only if said user information is valid. The Applicants respectfully submit the 
Examiner's attempt to equate port filtering with restricting access to said one of said plurality of 
input ports in accordance with a user policy associated with said user information only if said 
user information is valid as required by Claim 1 is improper. For these reasons, the 35 U.S.C. § 
102 Rejection of Claim 1 is unsupported by the cited art of record. Thus, a prima facie case has 
not been established and the rejection must be withdrawn. 
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Claims 1 3 and 23 

Claim 13 is a method claim corresponding to apparatus claim 1 . Claim 23 is a system 
claim corresponding to apparatus claim 1. Claim 1 being allowable, Claims 13 and 23 must be 
allowable for at least the same reasons as Claim 1 . 

Dependent Claims 2-3, 6-7, IK 14-15, 17, 24-25, and 28-29 

Claims 2-3, 6-7, and 1 1 depend from Claim 1. Claims 14-15 and 17 depend from Claim 
13. Claims 24-25 and 28-29 depend from Claim 23. Claims 1,13, and 23 being allowable, 
Claims 2-3, 6-7, 11, 14-15, 17, 24-25, and 28-29 must also be allowable for at least the same 
reasons as Claims 1,13, and 23. 

Claim 3 

Claim 3 recites: 

The network access device of claim 1 , wherein said control logic is adapted to 
authenticate said user information in accordance with an IEEE 802. Ix 
protocol. 

The Examiner states: 

... Kanuri et al. teaches the network access device of claim 1, wherein said control 
logic is adapted to authenticate said user information in accordance with an IEEE 
802.1x protocol (Col 3, starting at line 36: IEEE 802.3). 12 

The Applicant respectfully disagrees. In support of the Examiner's contention, the Examiner 

refers to a portion of Kanuri et al. that discloses sending and receiving layer 2 data packets 

according to the IEEE 802.3 protocol. The IEEE 802. IX protocol enables authenticated access 



11 Kanuri et al. at col. 5 11. 43-59. 

12 Office Action at p. 5. 
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to IEEE 802 media, including Ethernet, Token Ring, and 802.1 1 wireless LANs. 13 The IEEE 

802.3 protocol is described in RFC 3580, a copy of which is submitted with an Information 

Disclosure Statement filed herewith. The IEEE 802.3 protocol is not the same as the IEEE 

802. IX protocol. Kanuri et al. does not disclose the IEEE 802. IX protocol, nor does it disclose 

the IEEE 802.3 protocol in the context of user authentication. For this additional reason, the 35 

U.S.C. § 102 rejection of Claim 3 is unsupported by the cited art of record and the rejection must 

be withdrawn. 



The First 35 U.S.C. $ 103 Rejection 

Claims 4-5, 16, 26 and 27 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Kanuri et al. in view of Mate et al. , 14 among which no claims are independent 
claims. This rejection is respectfully traversed. 

According to the Manual of Patent Examining Procedure (M.P.E.P.), 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must 
be a reasonable expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. The 
teaching or suggestion to make the claimed combination and the reasonable 
expectation of success must both be found in the prior art, not in the applicant's 
disclosure. 15 



Claims 4 and 5 depend from Claim 1. Claim 16 depends from Claim 13. Claims 26 and 
27 depend from Claim 23. The arguments made above with respect to the 35 U.S.C. § 102 
rejection of independent Claims 1,13, and 23 apply here as well. The 35 U.S.C. § 102 rejection 



13 P. Congdon et al., RFC 3580 - IEEE 802. IX Remote Authentication Dial In User Service (RADIUS) Usage 
Guidelines, September 2003, at § 1. 

14 U.S. Patent No. 7,028,098 to Mate et al. 
15 M.P.E.P§2143. 



Page 22 of 30 



Attorney Docket No.: FOUND-0058 (034103-049) 
of Claims 1,13, and 23 is unsupported by the cited art of record because each and every element 

i 

as set forth in Claims 1, 13, and 23 is not found in Kanuri et al. Accordingly, the 35 U.S.C. § 
103 rejection of dependent claims 4-5, 16, and 26-27 based on Kanuri et al. in view of Mate et al 
is also unsupported by the cited art of record. Thus, a prima facie case has not been established 
and the rejection must be withdrawn. 



Claim 4 

Claim 4 recites: 

The network access device of claim 1 , wherein said user policy identifies an 
access control list. 

The Examiner states: 

... Kanuri et al. fails to disclose network access device wherein said user policy 
identifies an access control list. However, Mate et al. discloses network access 
device wherein said user policy identifies an access control list (Col 5, starts at 
line 60; Col 10, starts at line 45; policy; ACL). Mate et al. and Kanuri et al. are 
analogous art because they are from the same field of endeavor of secure network 
communication. At the time of invention, it will be obvious to a person of 
ordinary skill in the art to combine the teachings of Mate et al. with Kanuri to 
design an apparatus wherein user policy identifies an access control list to 
facilitate a managed packet filtering based on port or flow information. 16 

The Applicant respectfully disagrees. One of ordinary skill in the art would not be motivated to 

combine Kanuri et al. with Mate et al. because Mate et al. teaches away from the combination. 

Mate et al. recites: 

Policy-based routing flows are determined to have lower priority and are assigned 
to partition 36b. Policy based routing flows can include data classified by Access 
Control Lists (ACL) flows and traffic manager (TE) flows. Accordingly, MPLS 
flows and IP -VPN flows which have been assigned higher priority will be found 
in a subsequent lookup in flow TCAM 30 before ACL flows and TE flows which 
have been assigned a lower priority and MPLS flows or P VPN flows will 
subsume any matching ACL flows and TE flows in flow TCAM 30. 17 



Office Action at pp. 6-7. 
17 Mate et al. at col. 5 1. 63 to col. 6 1. 5. 
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As Mate et al. teaches assigning a lower priority to policy-based flows, which include ACL 

flows, one of ordinary skill in the art would not be motivated to combine Kanuri et al. with Mate 

et al. 

Furthermore, combining Kanuri et al with Mate et al. result in a complex network switch 
having multiple data flows with different priority levels, which would be incapable of ensuring 
switching of data packets at the wire rate. This would render the combination unsatisfactory for 
Kanuri et al. 's intended purpose of providing a network switch that is able to perform trunk- 
based switching of data packets at the wire rate. For this additional reason, one of ordinary 
skill in the art would not be motivated to combine Kanuri et al. with Mate et al. 

For these additional reasons, the 35 U.S.C. § 103 Rejection of Claim 4 is unsupported by 
the cited art of record and the rejection must be withdrawn. 

Claim 5 

Claim 5 recites: 

The network access device of claim 1 , wherein said user policy includes an access 
control list. 

The Examiner states: 

... Kanuri et al. fails to disclose the network access device wherein said user 
policy includes an access control list (Col 5, starts at line 60; Col 10, starts at line 
45; policy ..including ACL). 19 

The Applicants respectfully disagree. The arguments made above with respect to Claim 4 apply 

here as well. 



1 8 

See Kanuri et al . Abstract. 
19 Office Action at p. 7. 
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The Second 35 U.S.C. § 103 Rejection 

Claims 8-10, 18-22, 31-34 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Kanuri et al. in view of See et al. , 20 among which no claims are independent 
claims. This rejection is respectfully traversed. 



Claims 8-10 depend from Claim 1. Claims 18-22 depend from Claim 13. Claims 31-34 
depend from Claim 23. The arguments made above with respect to the 35 U.S.C. § 102 rejection 
of independent Claims 1,13, and 23 apply here as well. The 35 U.S.C. § 102 rejection of Claims 
1,13, and 23 is unsupported by the cited art of record because each and every element as set forth 
in Claims 1,13, and 23 is not found in Kanuri et al. Accordingly, the 35 U.S.C. § 103 rejection 
of dependent claims 8-10, 18-22, 31-34 based on Kanuri et al. in view of See et al. is also 
unsupported by the cited art of record. Thus, a prima facie case has not been established and the 
rejection must be withdrawn. 



Claim 8 

Claim 8 recites: 

The network access device of claim 1, wherein said control logic is adapted to 
send said user information to an authentication server and to receive an accept 
message from said authentication server if said user information is valid. 

The Examiner states: 

... Kanuri et al. fails to teach the network access device of claim 1, wherein said 
control logic is adapted to send said user information to an authentication server 
and to receive an accept message from said authentication server if said user 
information is valid. However, See et al. teaches control logic is adapted to send 
said user information to an authentication server and to receive an accept message 
from said authentication server if said user information is valid ( Col 6, starting at 
line 32; Col 10, starting at line 10; claims 25-27; authentication information 
including VLAN identifier; user identification information). Mate et al. and See 

20 U.S. Patent No. 6,874,090 to See et al. 
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et al. are analogous art because they are from the same field of endeavor of secure 
network communication. At the time of invention, it will be obvious to a person 
of ordinary skill in the art to combine the teachings of See et al. with Kanuri to 
design an apparatus further including an authentication server in order to facilitate 
proper VLAN authentication. 21 

The Applicants respectfully disagree for the reasons set forth below. 

As an initial matter, the Applicants submit the Examiner's statement regarding Mate et al. 
and See et al. allegedly being analogous art is irrelevant to a rejection under 35 U.S.C. § 103 
based on Kanuri et al. in view of See et al. 

Furthermore, the Applicants respectfully submit the Examiner's attempt to equate a 
VLAN identifier with the user information of Claim 8 is improper. Claim 8 requires that the 
control logic is adapted to send said user information to an authentication server and to receive 
an accept message from said authentication server if said user information is valid. Claim 1 from 
which Claim 8 depends requires that the user information is provided by a user of said user 
device. The VLAN identifier of See et al. cannot be said to be provided by a user of said device, 
nor can it be said to be user information. For this additional reason, the 35 U.S.C. § 103 
Rejection of Claim 8 is unsupported by the cited art of record and the rejection must be 
withdrawn. 



21 Office Action, pp. 7-8. 
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The Third 35 U.S.C. $ 103 Rejection 

Claims 38-43 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Kanuri et al. in view of See et al. and further in view of Volpano , among which Claims 38, 
40, and 42 are independent claims. This rejection is respectfully traversed. 



Claim 38 

Claim 38 recites: 

An apparatus for providing network security, comprising: 
a plurality of input ports; 

a switching fabric for routing data received on said plurality of input ports to at 

least one output port; and 
control logic adapted to: 

authenticate a physical address of a user device coupled to one of said plurality of 
input ports; 

drop packets from said user device if said physical address is invalid; 
authenticate user information provided by a user of said user device only if said 

physical address is valid; 
if authentication of said user information indicates said user information is 

invalid, block all traffic on said one of said plurality of input ports except for 

packets related to a user authentication protocol; 
if authentication of user information indicates said user information is valid, 

determine whether said user is associated with a VLAN supported by said 

apparatus by receiving a message from an authentication server, wherein said 

message comprises a VLAN identifier (ID) associated with said user 

information; 
if said user is not associated with said VLAN, 

assign said one of said plurality of input ports to a port default VLAN; and 
block all traffic on said one of said plurality of input ports except for packets 

related to said user authentication protocol; and 
if said user is associated with said VLAN, 

assign said one of said plurality of ports to said VLAN associated with said user; 
and 

restrict access to said one of said plurality of input ports in accordance with a user 
policy associated with said user information. 

The Examiner states: 



U.S. Patent No. 7,188,364 to Volpano . 
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... Kanuri et al. teaches an apparatus/ method/ system for providing network 
security, comprising: A data communication network (Col 3, starts at line 26; 
network packets); A network access device coupled to said data communication 
network (Col 3, starts at line 26; switch enabling communication); a plurality of 
input ports (Fig 1, 12.22; Col 3, lines 25-67; multiport switch); a switching fabric 
for routing data received on said plurality of input ports to at least one output port 
(Fig 1.28; Col 3, lines 25-67; switch fabric; Col 4, lines 7-52; layer 2 switch); and 
control logic adapted to: authenticate a physical address of a user device coupled 
to one of said plurality of input ports (Col 3, line 28 to Col 5 5 line 65: the switch; 
MAC module; switching (rules) logic; matching MAC addresses); authenticate 
user information provided by a user of said user device only if said physical 
address is valid (Col 3, line 54 to Cot 4, line 34; Col 5, lines 10-65; user or 
network nodes 1 attributes/ policies/ information; user defined policies/ attributes; 
authenticating VLAN field/ index/ information, and MAC addresses specific to 
user/ network node/ data frame); if authentication of user information indicates 
said user information is valid, determine whether said user is associated with a 
VLAN supported by said apparatus, wherein said message comprises a VLAN 
identifier (ID) associated with said user information (Col 5, lines 1-65; 
determining/ matching VLAN index/ information); if said user is associated with 
said VLAN, assign said one of said plurality of ports to said VLAN associated 
with said user (Cot 5, lines 1-20; Col 6, lines 1-40; switching logic assigning/ 
selecting ports); if said user is not associated with said VLAN, assign said one of 
said plurality of input ports to a port default VLAN (Col 5, lines 1-20; Col 6, lines 
1-40; switching logic assigning/ selecting ports); and restrict access to said one of 
said plurality of input ports in accordance with a user policy associated with said 
user information (Fig 2:40; associated port, MAC and VLAN information; Fig 3, 
step 70-106; Col 5, lines 43-60; if in step 74 the switching rules logic determined 
a match between MAC... VLAN index .... (then) checks in step 76 whether port 
...; the examiner interprets switching "rules" logic as policy; port filtering). 
Kanuri et al. fails to disclose expressly drop packets from said user device if said 
physical address is invalid; if authentication of said user information indicates 
said user information is invalid, block all traffic on said one of said plurality of 
input ports except for packets related to a user authentication protocol; receiving a 
message from an authentication server, wherein said message comprises a VLAN 
identifier (ID) associated with said user information; if said user is not associated 
with said VLAN, block all traffic on said one of said plurality of input ports 
except for packets related to said user authentication protocol. However, See et 
al. discloses drop packets from said user device if said physical address is invalid 
(Col 6, starting at line 32; filtering/ dropping packets based on MAC/ VLAN 
identifier); receiving a message from an authentication server, wherein said 
message comprises a VLAN identifier (ID) associated with said user information ( 
Col 6, starting at line 32; Col 10, starting at line 10; claims 25-27; authentication 
information including VLAN identifier; user identification information); Modified 
See at al - Kanun et al. apparatus/ method/ system fails to disclose if 
authentication of said user information indicates said user information is invalid, 
block all traffic on said one of said plurality of input ports except for packets 
related to a user authentication protocol if said user is not associated with said 
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VLAN, block all traffic on said one of said plurality of input ports except for 
packets related to said user authentication protocol. However, Volpano discloses 
if authentication of said user information indicates said user information is 
invalid, block all traffic on said one of said plurality of input ports except for 
packets related to a user authentication protocol (Col 5, starting at line 30; control 
frames; EAPOL); if said user is not associated with said VLAN, block all traffic 
on said one of said plurality of input ports except for packets related to said user 
authentication protocol (Col 5, starting at line 30; control frames; EAPOL). 
Volpano and Kanuri et al. are analogous art because they are from the same field 
of endeavor of VLAN utilizing bridges/ switches. At the time of invention, it will 
be obvious to a person of ordinary skill in the art to combine the teachings of 
modified See at al. - Kanuri et al. apparatus/ method/ system with Volpano to 
design an apparatus further adapted to drop/ filter packets by authenticating 
utilizing an authentication server, authentication protocol message containing 
VLAN identifier in order to provide a proper VLAN packet filtering. 

The Applicants respectfully disagree. The arguments regarding the 35 U.S.C. § 102 rejection of 
Claims 1-3,6-7, 11, 13-15, 17, 23-25, and 28-29 based on Kanuri et al , and the 35 U.S.C. § 103 
rejection of Claims 8-10, 1 8-22, and 31-34 based on Kanuri et al. in view of See et al. apply here 
as well. For this reason, the 35 U.S.C. § 103 Rejection of Claim 38 is unsupported by the cited 
art of record and the rejection must be withdrawn. 



Claims 40 and 43 

Claim 40 is a method claim corresponding to apparatus claim 38. Claim 42 is a system 
claim corresponding to apparatus claim 38. Claim 38 being allowable, Claims 40 and 42 must 
also be allowable for at least the same reasons as Claim 38. 



Dependent Claims 39, 41, and 43 

Claims 39, 41, and 43 depend from Claims 38, 40, and 42, respectively. Claims 38, 40, 
and 42 being allowable, Claims 39, 41, and 43 must also be allowable for at least the same 
reasons as Claims 38, 40, and 42. 



Office Action, pp. 9-12. 
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In view of the foregoing, it is respectfully asserted that the claims are now in condition 
for allowance. 

Conclusion 

It is believed that this Amendment places the above-identified patent application into 
condition for allowance. Early favorable consideration of this Amendment is earnestly solicited. 

If, in the opinion of the Examiner, an interview would expedite the prosecution of this 
application, the Examiner is invited to call the undersigned attorney at the number indicated 
below. 

The Applicant respectfully requests that a timely Notice of Allowance be issued in this 

case. 

Please charge any additional required fee or credit any overpayment not otherwise paid or 
credited to our deposit account No. 50-1698. 



Respectfully submitted, 

Thelen Reid Brown 
Raysman & Steiner LLP 



Dated: October 18, 2007 




John P. Schaub 
Reg. No. 42,125 
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